This is a priliminary specification of an extension to the MacBinary II Standard to allow MacBinary to incorporate a directory tree in a similar way to a unix tar file. This is done by a fairly simple extension to the standard (which is documented seperately, and which you should be familiar with before reading this), basically, I defined a 128 byte block that marks the start of a folder, and another one that marks the end of the folder, and then set it up like this:
start block for folder "Folder1"
file1 - standard macbinary format
file2
start block for "Folder2"
file3
end block
end block
While the end block doesn't actually need to contain any information, its format is similar to the header block for consistency.
Start Block:
Offset 000-version 1 - this is incomptible with previous decoders.
Offset 001-Byte, Length of foldername (must be in the range 1-63)
Offset 002-1 to 63 chars, foldername (only "length" bytes are significant,
the rest should be zero).
Offset 065-Long Word, file type - 'fold'
Offset 069-Long Word, file creator - $FFFFFFFF
Offset 073-Byte, original Finder flags of folder (high byte)
Offset 074-Byte, zero fill, must be zero for compatibility
Offset 075-Word, folder's vertical position within its window.
Offset 077-Word, folder's horizontal position within its window.
Offset 079-Word, folder's window or folder ID.
Offset 081-Byte, "Protected" flag (in low order bit).
Offset 082-Byte, zero fill, must be zero for compatibility
Offset 083-Long Word, Data Fork length 0
Offset 087-Long Word, Resource Fork length 0
Offset 091-Long Word, Folder's creation date
Offset 095-Long Word, Folder's "last modified" date.
Offset 099-Word, length of Get Info comment to be sent after the resource
fork (if implemented, see below).
*Offset 101-Byte, Finder Flags, bits 0-7. (Bits 8-15 are already in byte 73)
*Offset 116-Long Word, Length of total files when packed files are unpacked.
This may be zero to avoid having to preparse the folder when
creating the MacBinary file.
*Offset 120-Word, Length of a secondary header. If this is non-zero,
Skip this many bytes (rounded up to the next multiple of 128)
This is for future expansion only, when sending files with
MacBinary, this word should be zero.
*Offset 122-Byte, Version number of Macbinary II - 130
*Offset 123-Byte, Minimum MacBinary II version needed to read this file - 130
*Offset 124-Word, CRC of previous 124 bytes
NOTE: The secondary header length MAY be non-zero, and if so, the secondary header immediately follows the Start Block, padded to a multiple of 128 bytes as usual.
NOTE: The comment length MAY be non-zero, and if so, the comment immediately follows the Start Block or secondary header, padded to a multiple of 128 bytes as usual.
End Block:
Offset 000-version 1 - this is incomptible with previous decoders.
Offset 065-Long Word, file type - 'fold'
Offset 069-Long Word, file creator - $FFFFFFFE
*Offset 116-Long Word, Length of total files when packed files are unpacked.
This may be zero.
*Offset 120-Word, Length of a secondary header. If this is non-zero,
Skip this many bytes (rounded up to the next multiple of 128)
This is for future expansion only, when sending files with
MacBinary, this word should be zero.
*Offset 122-Byte, Version number of Macbinary II - 130
*Offset 123-Byte, Minimum MacBinary II version needed to read this file - 130
*Offset 124-Word, CRC of previous 124 bytes
NOTE: This block is static except for the total length field, which may be zero as well, in which case its totally static.
You should recognize the Start and End blocks by the version, file type and creator fields. Decoders MUST NOT rely on ANY other fields in the End Block being valid. Encoders MAY fill them out to look like a start block, or may zero-fill them. Encoders SHOULD zero-fill any bytes not explicitly set - this applies to all header blocks and all padding.
All internal files should have version 0, MacBinary II version 129,129.
An extended MacBinary file MUST start with a Start Block. Thus a MacBinary II+ file is either:
